Escrow Payment System for Transactions

ABSTRACT

An apparatus, method, and computer-readable storage medium for coordinating payment between a payor and a payee of a transaction for a contractual obligation includes electronically receiving of payor and payee bank account information, electronically receiving transaction information, and electronically transmitting a debit request to a payment processor. The debit request includes instructions to create a discrete financial account for the online transaction, debit an amount from the payor&#39;s bank account, and hold the debited amount in the discrete financial account. After the contractual obligation is satisfied, a credit request is electronically transmitted to a payment processor. The credit request includes instructions to credit the payee&#39;s bank account with a payment amount from funds held in the discrete financial account.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to an escrow payment system for facilitatingpayment between a payor and a payee, such as a buyer and a sellerconducting an online transaction.

2. Description of the Related Art

The Internet has become a preferred global platform for buying andselling goods and services. Using the Internet, potential buyers andsellers conduct and manage these transactions without needing to bephysically present to complete the transaction. Various shippingcompanies are available to deliver purchased goods.

Numerous online web sites exist to facilitate these sales and unitepotential buyers and sellers. These sites customarily allow participantsto list items for sale or items that a participant seeks to purchase,and permit anyone on the Internet to at least view, browse, and/orsearch these listings. Interested sellers and buyers are then connectedwith each other.

One popular type of these web sites is online auction sites. Auctionsutilize a free-market approach to assess the actual market value of thegoods and services, by introducing competition and allowing themarketplace to set the pricing according to demand.

Online auctions can be organized in many different formats. Two distinctapproaches are the “forward auction” and “reverse auction”configurations. In a forward auction, a seller creates an auctionlisting for one or more goods or services, and the bidders are buyerslooking to purchase the auction item(s) in the listing. Customarily, theseller will set a low initial price, and each successive bidder willsubmit a successively higher bid until the auction ends. The highestbidder at the end of the auction is the winner and receives the auctionitem(s) in exchange for payment of the bid amount.

In a reverse auction, it is a buyer, not a seller, who creates anauction listing. The buyer is seeking a particular good or service (ormultiple goods or services) and creates the auction listing with arequest for such items, seeking sellers to accommodate the request. Thebidders in a reverse auction are potential sellers looking toaccommodate the items for a price. The buyer will often set a highinitial price, and each successive bidder will submit a successivelylower bid until the auction ends. The lowest bidder at the end of theauction is typically the winner and receives the bid amount in exchangefor providing the requested item(s) to the buyer. It is noted that someauctions may incorporate award criteria besides simply pricing. Forinstance, in a reverse auction, a buyer may utilize award criteria otherthan price, such that the lowest bidder may not necessarily be thewinner as selected by the buyer.

Many auction transactions involve buyers and sellers who are unfamiliarwith each other prior to participating in the auction. Thisunfamiliarity creates inherent risks in conducting the transaction.Accordingly, an auction bidder may rely on word-of-mouth, reputation,ratings, written feedback, and/or any other information relating to theother party, in predicting the other party's reliability in completing atransaction. Such reliability may be a factor as to whether the bidderdecides to enter a bid.

One particular risk arises during the conventional transfers of theauction payment and the goods between the buyer and the seller. When anup-front payment is required prior to shipment of the goods, the buyerholds a risk that the seller does not ship the goods even afteraccepting the payment, or that the goods are defective. Meanwhile, theseller holds a risk that the buyer's payment is defective, but suchdefect is not revealed until after the seller ships the goods.

Conversely, if payment is to be provided following shipment and/orinspection of the goods, the seller holds a risk that the buyer will notmake the required payment or that a payment will be defective.

One approach to reduce the risk in these types of transactions is to usean escrow service. A typical escrow service is a neutral third-partyvendor appointed to facilitate the transaction by holding the buyer'spayment during pendency of the transaction, and then distributing thepayment to designated parties such as the seller after the delivery iscomplete. With this approach, the escrow service assures the seller thatthe buyer has indeed submitted a payment, and that the submitted fundsare genuine. The escrow service typically charges a fee for theseservices. It will be appreciated that the escrow service mayalternatively or additionally hold and distribute the auction goods inaccordance with the arrangement between the buyer and seller.

In managing the payment for the auction, the escrow service typicallycollects the payment from the buyer and then maintains the payment in afinancial account. Upon acceptance of the goods by the buyer, the escrowservice distributes the payment from the financial account to theseller. The payments may be provided in paper form (e.g., check) or maybe provided via ACH or wire transfer.

Typical escrow services are configured to handle individual transactionsand typically incorporate manual activity to conduct each individualtransaction. An escrow service may employ mechanisms to identify anddistinguish received funds.

One conventional approach adopted by escrow services is to allocate andassociate a financial account with a specific participant. The specificparticipant may be either the particular buyer or the particular seller.This financial account is then re-used for all subsequent transactionsinvolving the same participant. The financial account may be situated ata financial institution, such as a bank.

Escrow services using this approach may prefer a customer base havingfrequent return business, to minimize expenses and labor associated withcreating an individual account for each new customer. These expenses andlabor may inhibit the potential growth of the escrow service.

This approach also results in commingling of funds. If the same buyerand seller engage in multiple transactions, the same account iscontinuously re-used in all the transactions. If the account isassociated with the buyer, payments for subsequent transactionsinvolving the buyer, but a different seller, may still be stored in thisaccount. If the account is associated with the seller, payments forsubsequent transactions involving the seller, but a different buyer, maystill be stored in this account.

If the participant (e.g., buyer) is involved with numerous concurrenttransactions, the accounting required to track each payment may becomeoverwhelming. Moreover, the funds from different transactions (e.g.,from different sellers) become commingled.

Some basic escrow services may even forego accounts for eachparticipant. In such circumstances, the escrow service may simply storepayment funds in its general financial account, and attempt to maintainthe appropriate accounting. With this approach, funds are continuouslybeing commingled.

The growing presence of escrow services have also increased theirpopularity among other transactions beyond those conducted on theInternet and/or via auctions. Indeed, an escrow service can be appliedfor any transaction between a payor and a payee.

On top of commingling concerns, governmental entities have institutedregulations for financial institutions, requiring them to verify theidentity of their customers prior to conducting business with them.These government-mandated security checks are generally known as “KnowYour Customer” (KYC) checks, and may verify that a customer has not beensuspected of involvement in criminal activity such as terrorism ormoney-laundering. As an example, in the United States, the followingsources may be queried:

-   -   (1) Bureau of Industry & Security    -   (2) DTC Debarred Parties    -   (3) Enterprise Wide Internal Watch list    -   (4) EU Consolidated    -   (5) Factiva PFA (Africa, Asia, Canada, Europe, Middle East,        North America, South America, Unknown, USA)    -   (6) Financial Action Task Force    -   (7) FBI Hijack Suspects    -   (8) FBI Most Wanted    -   (9) FBI Most Wanted Terrorists    -   (10) FBI Seeking Information    -   (11) FBI Top Ten Most Wanted    -   (12) Nonproliferation Sanctions    -   (13) OFAC Non-SDN Entities    -   (14) OFAC Sanctions    -   (15) OFAC SDN    -   (16) Primary Money Laundering Concerns (Countries)    -   (17) Primary money Laundering Concerns (Entities)    -   (18) Terrorist Exclusion List    -   (19) UN Consolidated List

However, escrow services may not be equipped to easily conduct these KYCchecks. As these checks should be performed prior to any transfer ofpayment, an escrow service may be overburdened with KYC checks fortransactions having many potential participants (e.g., potential biddersin an auction).

Financial institutions, on the other hand, are equipped to conduct KYCchecks, as they have these mechanisms in place to verify new customers.

Accordingly, there is a need in the art for an escrow service thatefficiently facilitates and holds a payment between a payor and a payee,while avoiding the commingling and mis-identification of funds. There isalso a need in the art for an efficient and secure system forcoordinating a transaction between an online site (such as an auctionsite), an escrow service, and a financial institution that processes thetransaction payment. There is further a need in the art for an escrowservice that efficiently conducts KYC checks prior to initiating apayment transfer and hold.

SUMMARY OF THE INVENTION

The present invention addresses the challenges in the art discussedabove. With increasing concerns over lax accounting practices, customersof escrow services may insist that funds for every transaction beseparately stored, so as to avoid any commingling of these funds. Thesecustomers may even insist that funds from different transactions, eveninvolving the same buyer and seller, be separately held. Customers mayalso demand frequent status updates on the transfers of each of thesefunds.

In the following description, it will be appreciated that the invention,in one aspect, relates to (1) the non-commingling of funds (e.g., anauction service's operating account is maintained separately from thoseof its buyers and sellers); and (2) the preservation of identity offunds on a transaction level (e.g., identity of funds is maintained forevery transaction, not simply for a specific buyer or seller).

An aspect of the invention relates to a method of coordinating paymentbetween a payor and a payee of a transaction for a contractualobligation, comprising electronically receiving bank account informationfrom an online entity administering the transaction, the bank accountinformation including information on (1) a payor bank accountcorresponding to the payor, and (2) a payee bank account correspondingto the payee; electronically receiving transaction information from theonline entity, the transaction information including a payment amount tobe paid by the payor to the payee for the contractual obligation;electronically transmitting a debit request to a payment processor, thedebit request including instructions to (1) create a discrete financialaccount specific to the transaction, (2) debit, from the payor bankaccount, a debit amount equal to or greater than the payment amount, (3)transfer the debit amount to the discrete financial account, and (4)hold the debit amount in the discrete financial account; andelectronically transmitting, after a confirmation that the contractualobligation has been at least partially satisfied, a credit request tothe payment processor, the credit request including instructions to (1)transfer a credit amount from the discrete financial account, and (2)credit, to the payee bank account, the payment amount, wherein said bankaccount information electronic receiving step, said transactioninformation electronic receiving step, said debit request electronictransmitting step, and said credit request electronic transmitting stepare implemented using at least one processor and at least one memory.

Another aspect of the invention relates to a method of coordinating aplurality of payments, each payment corresponding to a transactionbetween a payor and a payee for a contractual obligation, comprisingelectronically receiving, for each of the transactions, bank accountinformation from an online entity administering the transaction, thebank account information including information on (1) a payor bankaccount corresponding to the respective payor, and (2) a payee bankaccount corresponding to the respective payee; electronically receiving,for each transaction, transaction information from the online entity,the transaction information including a payment amount to be paid by therespective payor to the respective payee for the respective contractualobligation; electronically transmitting, for each of the transactions, adebit request to a payment processor, the debit request includinginstructions to (1) create a discrete financial account specific to thetransaction, (2) debit, from the respective payor bank account, a debitamount equal to or greater than the respective payment amount, (3)transfer the debit amount to the discrete financial account, and (4)hold the debit amount in the discrete financial account; andelectronically transmitting, for each of the transactions and afterconfirmation that the contractual obligation has been at least partiallysatisfied, a credit request to the payment processor, the credit requestincluding instructions to (1) transfer a credit amount from therespective discrete financial account, and (2) credit, to the respectivepayee bank account, the respective payment amount, wherein said bankaccount information electronic receiving step, said transactioninformation electronic receiving step, said debit request electronictransmitting step, and said credit request electronic transmitting stepare implemented using at least one processor and at least one memory.

Yet another aspect of the invention relates to a method of coordinatinga plurality of payments, each payment corresponding to an onlinetransaction between a seller and a buyer for an item, comprisingelectronically receiving, for each of the online transactions, bankaccount information from an online entity administering the onlinetransaction, the bank account information including information on (1) aseller bank account corresponding to the respective seller, and (2) abuyer bank account corresponding to the respective buyer; electronicallyreceiving, for each of the online transactions, transaction informationfrom the online entity, the transaction information including a paymentamount to be paid by the respective buyer to the respective seller forthe respective item; electronically transmitting a batch debit requestto a payment processor, the batch debit request including instructionsto, for each of the online transactions, (1) create a discrete financialaccount specific to the online transaction, (2) debit, from therespective buyer bank account, a debit amount equal to or greater thanthe respective payment amount, (3) transfer the debit amount to thediscrete financial account, and (4) hold the debit amount in thediscrete financial account; and electronically transmitting a batchcredit request to the payment processor, the batch credit requestincluding instructions to, for each of the online transactions having aconfirmation that the respective buyer has received the respective item,(1) transfer a credit amount from the respective discrete financialaccount, and (2) credit, to the respective seller bank account, thepayment amount, wherein said bank account information electronicreceiving step, said transaction information electronic receiving step,said debit request electronic transmitting step, and said credit requestelectronic transmitting step are implemented using at least oneprocessor and at least one memory

Still another aspect of the invention relates to a method ofcoordinating payment between a seller and a buyer of an onlinetransaction for an item, comprising electronically receiving bankaccount information, the bank account information including informationon (1) a seller bank account corresponding to the seller, and (2) abuyer bank account corresponding to the buyer; checking the seller bankaccount and the buyer bank account for security compliance;electronically receiving transaction information, the transactioninformation including a payment amount to be paid by the buyer to theseller for the item; electronically creating a discrete financialaccount specific to the online transaction; electronically debiting,from the buyer bank account, a debit amount equal to or greater than thepayment amount; electronically transferring the debit amount to thediscrete financial account; holding the debit amount in the discretefinancial account; electronically receiving a notification that thebuyer has received the item; electronically transferring a credit amountfrom the discrete financial account; and electronically crediting, tothe seller bank account, the credit amount, wherein said bank accountinformation electronic receiving step, said transaction informationelectronic receiving step, said electronic creating step, saidelectronic debiting step, said debit amount electronic transferringstep, said notification electronic receiving step, said credit amountelectronic transferring step, and said electronic crediting step areimplemented using at least one processor and at least one memory.

Another aspect of the invention relates to an apparatus for coordinatingpayment between a payor and a payee of a transaction for a contractualobligation, comprising a bank account information reception module thatreceives, from an online entity administering the transaction, bankaccount information including information on (1) a payor bank accountcorresponding to the payor, and (2) a payee bank account correspondingto the payee; a transaction information reception module that receives,from the online entity, the transaction information including a paymentamount to be paid by the payor to the payee for the contractualobligation; a debit request transmission module that transmits, to apayment processor, a debit request including instructions to (1) createa discrete financial account specific to the transaction, (2) debit,from the payor bank account, a debit amount equal to or greater than thepayment amount, (3) transfer the debit amount to the discrete financialaccount, and (4) hold the debit amount in the discrete financialaccount; and a credit request transmission module that transmits, aftera confirmation that the contractual obligation has been at leastpartially satisfied, a credit request to the payment processor, thecredit request including instructions to (1) transfer a credit amountfrom the discrete financial account, and (2) credit, to the payee bankaccount, the payment amount.

A further aspect of the invention relates to a computer program productcomprising a non-transitory computer readable medium having controllogic stored thereon for causing a computer to coordinate paymentbetween a payor and a payee of a transaction for a contractualobligation, the control logic comprising computer readable program codewhich, when executed, causes the computer to perform the steps ofelectronically receiving bank account information from an online entityadministering the transaction, the bank account information includinginformation on (1) a payor bank account corresponding to the payor, and(2) a payee bank account corresponding to the payee; electronicallyreceiving transaction information from the online entity, thetransaction information including a payment amount to be paid by thepayor to the payee for the contractual obligation; electronicallytransmitting a debit request to a payment processor, the debit requestincluding instructions to (1) create a discrete financial accountspecific to the transaction, (2) debit, from the payor bank account, adebit amount equal to or greater than the payment amount, (3) transferthe debit amount to the discrete financial account, and (4) hold thedebit amount in the discrete financial account; and electronicallytransmitting, after a confirmation that the contractual obligation hasbeen at least partially satisfied, a credit request to the paymentprocessor, the credit request including instructions to (1) transfer acredit amount from the discrete financial account, and (2) credit, tothe payee bank account, the payment amount.

Further features and advantages, as well as the structure and operation,of various example embodiments of the present invention are described indetail below with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the example embodiments of the inventionpresented herein will become more apparent from the detailed descriptionset forth below when taken in conjunction with the drawings. Likereference numbers between two or more drawings can denote identical orfunctionally similar elements unless the description indicatesotherwise.

FIG. 1 is a system diagram showing an online auction system according toone aspect of the invention.

FIG. 2 is a block diagram showing physical components of the auctionserver according to one aspect of the invention.

FIG. 3 is a block diagram showing software components running on theauction server according to the same aspect of the invention asillustrated in FIG. 2.

FIG. 4 is a block diagram showing physical components of the escrowpayment server according to one aspect of the invention.

FIG. 5 is a block diagram showing software components running on theescrow payment server according to the same aspect of the invention asillustrated in FIG. 4.

FIG. 6 is a block diagram showing physical components of the paymentprocessor server according to one aspect of the invention.

FIG. 7 is a block diagram showing software components running on thepayment processor server according to the same aspect of the inventionas illustrated in FIG. 6.

FIG. 8 is an organization chart showing the relationships of entitiesassociated with the online auction system.

FIGS. 9A-9C are flow-charts with steps for implementing a first methodfor operating the escrow payment server and payment processing server.

FIG. 10 is a sequence diagram showing the sequence of steps by eachentity, in executing the first method.

FIG. 11 is a block diagram showing the financial accounts involved inthe online auction system of FIG. 1.

FIG. 12 is a sequence diagram showing a first method of processing fundtransfers according to a real-time processing methodology that may beutilized with the invention.

FIG. 13 is a sequence diagram showing a second method of processing fundtransfers according to a batch processing methodology that may beutilized with the invention.

FIG. 14 is a sequence diagram showing a third method of processing fundtransfers according to a hybrid real-time/batch processing methodologythat may be utilized with the invention.

FIG. 15 is a diagram showing an example of a release file that may beused with the third method of processing fund transfers.

FIG. 16 is a system diagram showing an online transaction systemaccording to another aspect of the invention.

FIG. 17 is a block diagram showing physical components of the onlinebusiness according to an aspect of the invention.

FIG. 18 is a block diagram showing software components running on theonline business according to the same aspect of the invention asillustrated in FIG. 17.

FIGS. 19A-19C are flow-charts with steps for implementing a secondmethod for operating the escrow payment server and payment processingserver.

FIG. 20 is a system diagram showing an online transaction systemaccording to a third aspect of the invention.

FIGS. 21A-21B are flow-charts with steps for implementing a third methodfor operating the escrow payment server and payment processing server.

FIG. 22 is a sequence diagram showing the sequence of steps by eachentity, in executing the third method.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows an online auction system 100 that may carry out thefeatures in accordance with one aspect of the present invention. Auctionsystem 100 includes an auction server 110, an escrow payment service(EPS) server 150, and a payment processor server 160. Auction server 110is connected to a network 120 (such as the Internet) via a network link121. EPS server 150 is connected to network 120 via a network link 122.Payment processor server 110 is connected to network 120 via a networklink 123. It will be appreciated that auction server 110, EPS server150, and payment processor server 160 may alternatively be connectedthrough dedicated and/or private network links or other methods ofinformation exchange.

The auction system 100 also includes at least one auction-listingsubmission device 130 and at least one bid submission device 140.Auction-listing submission device 130 is connected to network 120 via anetwork link 131, and bid submission device 140 is connected to network120 via a network link 141. In a preferred embodiment, auction-listingsubmission device 130 and bid submission device 140 are personalcomputers. However, it will be appreciated that the devices mayalternatively include cellular telephones (e.g., smartphones), tablets,terminals, or any other devices capable of submitting electronicinformation to the auction system 100.

Auction-listing submission device 130 is operated by an individual orother entity (e.g., corporate or government) desiring to initiate anauction listing. In the case of a forward auction, the auction listingis for the sale of one or more goods or services, whereas for a reverseauction, the auction listing is a request for the desired purchase ofone or more goods or services.

Bid submission device 140 is operated by an individual or other entity(e.g., corporate or government) desiring to submit a bid for the auctionlisting initiated by an auction-listing submission device 130. In thecase of a forward auction, the bid is for the purchase of the one ormore goods or services, whereas for a reverse auction, the bid is forthe sale of the one or more goods or services, thereby satisfying therequest for the desired purchase.

It will be understood that auction system 100 may include multipleauction-listing submission devices 130 and multiple bid submissiondevices 140, each connected to network 120. It will also be appreciatedthat any auction-listing submission device 130 and/or bid submissiondevice 140 may communicate with the auction server 110 via a webbrowser, dedicated software, text messaging, or any other form of datacommunication.

It will be further appreciated that payment processor associated withpayment processor server 160 may be a financial institution or any otherservice capable of processing and/or transferring funds. It will beadditionally appreciated that the payment processor may actuallyconstitute a plurality of entities working in coordination to providethe specified functionality of a payment processor.

FIG. 2 shows various hardware features of auction server 110. Auctionserver 110 includes a CPU 111, memory 112 (such as RAM), data storage113 (such as a hard disk or solid state drive), and a network interface114.

CPU 111 processes instructions stored in memory 112, in accordance withoperating system and auction software stored in data storage 113 forexecution by auction server 110. Data storage 113 also stores data forthe auction software, such as information relating to auction listings,bids, and bidders.

Network interface 114 enables auction server 110 to communicate withnetwork 120 over network link 121.

FIG. 3 shows the software modules for the auction software executed onauction server 110. Auction server 110 executes a bidding module 310.Bidding module 310 may include software for conducting an auction, suchas accepting an auction listing, accepting bids, and notifyingcorresponding parties of the auction status and activities. Biddingmodule 310 may optionally coordinate the exchange of items and fundsbetween the final parties.

Auction server 110 also executes an EPS interface module 320. EPSinterface module 320 exchanges data with EPS server 150 using networkinterface 114.

Auction server 110 further executes a user authentication module 330.User authentication module 330 authenticates the operators ofauction-listing submission devices 130 and bid submission devices 140.User authentication module 330 thus confirms the identity of the partiesinvolved in an auction.

FIG. 4 shows various hardware features of EPS server 150. EPS server 150includes a CPU 410, memory 420 (such as RAM), data storage 430 (such asa hard disk or solid state drive), and a network interface 440.

CPU 410 processes instructions stored in memory 420, in accordance withoperating system and auction software stored in data storage 430 forexecution by EPS server 150. Data storage 430 also stores data for theescrow payment software, such as information relating to auctionlistings, bids, and bidders.

Network interface 440 enables EPS server 150 to communicate with network120 over network link 122.

FIG. 5 shows the software modules for the software executed on EPSserver 150. EPS server 150 executes an EPS execution module 510. EPSexecution module 510 may include software for maintaining auctiontransaction information, such as buyer/seller information, deliverytracking and confirmation, and a timer for a buyer to inspect receivedauction goods.

EPS server 150 also executes an EPS account management module 520. EPSaccount management module 520 manages the banking information for buyersand sellers, ensuring that these participants have valid bankinginformation and comply with KYC checks.

EPS server 150 further executes an auction server interface 530 and apayment processor interface 540. Auction server interface 530 exchangesdata with auction server 110 using network interface 440, while paymentprocessor interface 540 exchanges data with payment processor server 160using network interface 440.

FIG. 6 shows various hardware features of payment processor server 160.Payment processor server 160 includes a CPU 610, memory 620 (such asRAM), data storage 630 (such as a hard disk or solid state drive), and anetwork interface 640.

CPU 610 processes instructions stored in memory 620, in accordance withoperating system and auction software stored in data storage 630 forexecution by payment processor server 160. Data storage 630 also storeseach participant's bank account information, KYC check complianceinformation, and timer information for buyers to inspect received goods.

Network interface 640 enables payment processor server 160 tocommunicate with network 120 over network link 123.

FIG. 7 shows the software modules for the software executed on paymentprocessor server 160. Payment processor server 160 executes an accountmanagement module 710. Account management module 710 may includesoftware for receiving and processing funds transfer requests,sub-account creation and termination requests, KYC check requests, andother financial requests, and for generating notices to these requests.

Payment processor server 160 also executes a sub-account managementmodule 720. Sub-account management module 720 manages sub-accounts,including the creation and termination of individual sub-accounts, andinformation relating to each sub-account. It will appreciated that asub-account may be any variety of financial account within the paymentprocessor, including, for example, an account bearing an ACHidentification number, a logical account only accessible internallywithin the payment processor, or any other electronic record whichuniquely identifies a transaction, funds corresponding to thetransaction, and the available balance for that transaction.

Payment processor server 160 also executes a funds transfer module 730.Funds transfer module 730 processes requests to transfer funds to, orfrom, a sub-account to a general account, along with requests totransfer funds between internal accounts and external or third-partyaccounts. For example, transfers between ACH accounts may be processedvia the ACH network, while transfers between internal accounts mayinvolve the updating of the corresponding logical account information orelectronic records.

Payment processor server 160 additionally executes an EPS serverinterface 740. EPS server interface 530 exchanges data with EPS server150 using network interface 640.

FIG. 8 shows an example of an organization structure that may be usedwith the invention. The organization structure includes the auctionserver, EPS, and the payment processor.

As seen in FIG. 8, an auction service is associated with entities suchas government or private business entities. Each entity may beassociated with various organizations, or levels of organizations. Forexample, the organization may include the various departments (e.g.,business, human resources) and groups associated with the organization.Each department and/or group may participate in the auction service topurchase and/or sell goods or services.

An auction buy is involved with a specific buyer within an organizationof the purchasing entity and a specific seller within an organization ofa selling entity. Each organization and entity sends information to, andreceives information from, EPS. This transfer of information may becoordinated directly with the organization, or may first be channeledvia a higher level of the entity's organizational structure. Forinstance, the system may only permit registration of organizations thatpossess a tax identification number (e.g., Employer IdentificationNumber (EIN)). In such an instance, if the organization is only alogical unit of a parent entity, the organization may only participateas a representative of its parent entity. However, it will beappreciated that the system may alternatively permit any organization orgroup to participate.

The payment processor could be a global entity capable of communicatingwith EPS on a global scale. The payment processor includes a paymententity, which receives information from a line of business division. Theline of business division coordinates the lines of business between thevarious organizations utilizing the auction service. The line ofbusiness division in turn receives individual order information from thebuyers and sellers affiliated with these organizations.

FIGS. 9A-9C show a method of operating the auction server 110, EPSserver 150, and payment processor server 160 in accordance with a firstembodiment of the invention. FIG. 10 is a graphical representation ofthe execution of the method of FIGS. 9A-9C, with the respective stepsperformed by the buyer, the seller, EPS, an online business (such as theauction service), and the payment processor. The steps are describedwith respect to a reverse auction. However, it will be appreciated thatthese steps are applicable to a forward auction or a transaction otherthan an auction.

In step S901, the auction server 110 captures buyer and/or sellerbanking information. This may include the banking information for allpotential buyers and sellers. That is, in a forward auction, the auctionserver 110 may capture the banking information for the seller and forall buyers desiring to participate in the auction. In a reverse auction,the auction server 110 may capture the banking information for the buyerand for all sellers desiring to participate in the auction.Alternatively, it will be appreciated that in a forward auction, onlythe seller's bank account information may be necessary at the start ofthe auction, and that in a reverse auction, only the buyer's bankaccount information may be necessary at the start of the auction. Assuch, it will be appreciated that the auction server 110 may initiallycapture only the buyer's bank account, and defer the capture of thewinning seller's bank account information until after the auction hasconcluded. In such an instance, only the winning seller's bank accountinformation is needed, and the remaining sellers' bank accountinformation would not be captured. The auction server 110 forwards thebanking information to the EPS server 150, which in turn forwards suchinformation to the payment processor server 160.

In step S902, the payment processor server 160 conducts validation andsecurity checks on the received banking information. The paymentprocessor server 160 transmits the results of these checks to the EPSserver 150, which in turn forwards the information to the auction server110. It will be appreciated that if both the buyer and potentialsellers' bank account information is processed, the auction server 110may be configured so as to prevent sellers and buyers from participatingin an auction until their banking information has been approved.Alternatively, if only the buyer's bank account information isprocessed, the auction server 110 may be configured merely to preventthe buyer from participating in the auction until the buyer's bankinginformation has been approved. It will be appreciated that the EPSserver 150 may itself be capable of conducting the validation andsecurity checks, and in such an instance, the EPS server 150 willperform such checks without involving the payment processor server 160.

In step S903, the auction server 110 conducts the auction. This stepincludes receiving bids from bidders, notifying parties of the status ofthe auction, and calculating leading bids.

In step S904, the auction server 110 awards an auction buy to a winningseller. The winning seller held the leading bid upon expiration of theauction. In circumstances where price is the sole metric for theordering of bids, the winning seller's bid price was below that ofcompeting bids. Alternatively, where additional or other metrics areused, the seller's offer was determined to be most advantageous over anycompeting bids. If the auction server 110 has not already captured theseller's banking information in step S901, the auction server 110captures such information here in step S904. In such an instance, theauction server 110 may separately request that the payment processorserver 160 conduct validation and security checks on the seller'sbanking information, and may temporarily suspend activity until theseller's banking information has been approved.

In step S905, the auction server 110 transmits the winning bidinformation to the EPS server 150.

In step S906, the EPS server 150 sends an instruction to the paymentprocessor server 160 with information regarding the buyer and theauction. This information includes at least the buyer's bank accountinformation, along with the amounts of the auction payment and fees fordebit from the buyer's account. Alternatively, if the buyer's bankaccount information is pre-stored and is identifiable by the EPS server150 and the payment processor server 160 using another identifier, thatother identifier may be used instead.

In step S907, the payment processor server 160 creates a unique anddiscrete financial account affiliated with the auction. This uniquefinancial account is also referred to herein as a sub-account. Thissub-account will subsequently store the funds debited from the buyer'sbank account, and is specific to the auction transaction. That is, thissub-account is different from all remaining sub-accounts, even in thecase where the seller of a first auction (or other transaction) is thesame as the seller of a second auction (or other transaction), or wherethe buyer of a first auction (or other transaction) is the same as thebuyer of a second auction (or other transaction).

In step S908, the payment processor server 160 initiates a debit fromthe buyer's bank account, for the amount of the auction and the fees,according to the information received in step S906. The paymentprocessor server 160 stores these debited funds in the sub-accountcreated in step S907. It will be appreciated that this debit may occurin at least one of two different techniques. First, the paymentprocessor server 160 may transfer received funds directly into thesub-account. Alternatively, the payment processor server 160 maytransfer received funds into a general account, and then immediatelytransfer these funds into the sub-account. The latter method may bepreferable so as to conceal the sub-account information from outsidefinancial institutions such as the buyer's bank. The latter method mayalso be preferable when sub-accounts are logical accounts or electronicrecords. In such an instance, the payment processor server 160 mayperform the first transfer from the buyer's bank account into a generalaccount via, for example, ACH, while performing the second transfer fromthe general account into the sub-account via an updating of theappropriate logical account or electronic record. The payment processorserver 160 may notify the EPS server 150 once the debit has beencompleted and the funds are stored in the sub-account.

In step S909, the EPS server 150 sends a notice to the auction server110 that the debit has been completed.

In step S910, the auction server 110 sends a notice to the seller toship the auction goods to the buyer.

In step S911, the seller employs a shipping service to ship the auctiongoods to the buyer.

In step S912, the shipping service delivers the auction goods to thebuyer.

In step S913, the seller provides proof of delivery to the auctionserver 110.

In step S914, the auction server 110 transmits the seller's proof ofdelivery to the EPS server 150.

In step S915, the EPS server 150 sends a request to the auction server110 to confirm with the buyer that the auction goods were delivered.

In step S916, the auction server 110 sends a notice to the buyer,requesting that the buyer confirm delivery of the auction goods.

In step S917, the buyer confirms the receipt of the auction goods, byresponding to the notice sent by the auction server 110 in step S915.

In step S918, the EPS server 150 starts a timer according to apredetermined time period. The predetermined time period is the periodprovided to the buyer to inspect the delivered auction goods and raisean objection as to the shipment. For instance, the buyer may object thatcertain auction goods are missing from the shipment. Or, the buyer mayobject that the delivered goods are defective or inconsistent with adescription of these goods provided by the seller during the auction.

In step S919, the EPS server 150 awaits an acceptance or an objectionfrom the buyer. If the buyer accepts the goods, the EPS server 150proceeds to step S920. If the buyer objects to the goods, the EPS server150 proceeds to step S921. If the buyer has not provided either anacceptance or an objection, the EPS server 150 proceeds to step S922.

In step S920, a buyer acceptance causes the auction server 110 totransmit such acceptance information to the EPS server 150, and the EPSserver 150 receives such information.

In step S921, an objection lodged by the buyer as to the auction goodscauses a dispute resolution proceeding and/or an arbitration proceedingto be commenced to resolve the dispute. Meanwhile, the payment processorserver 160 maintains the funds stored in the sub-account pending adispute resolution or an arbitration decision. It will be appreciatedthat the buyer or seller may initiate dispute resolution and/orarbitration via any acceptable method. For instance, the buyer mayinitiate the dispute resolution and/or arbitration via the auctionserver 110, which in turn notifies the EPS server 150 of this status.Alternatively, the buyer may initiate the dispute resolution and/orarbitration directly via the EPS server 150 or through any other means.

In step S922, the EPS server 150 determines whether the timer set instep S918 has expired. If the timer has not expired, the EPS server 150returns to step S919. If the timer has expired, the EPS server 150proceeds to step S923.

It will be appreciated that steps S918-S922 may be optional steps inaccordance with a desired operation of the system, and that the systemmay be operated such that delivery confirmation by the buyer and/orseller is a sufficient condition for disbursement of funds. In stepS923, the EPS server 150 sends a credit instruction to the paymentprocessor server 160 to disburse the funds in the sub-account.

In step S924, the payment processor server 160 initiates a disbursementof funds to the seller's bank account. These funds represent the paymentfor the auction goods, and customarily will equal the amount debited instep S908, less any fees that the auction service, the escrow paymentservice, and/or the payment processor deducts for its contributedservices in the transaction. The disbursement may occur in a similarmanner to the transfer(s) in step S908. That is, the payment processorserver 160 may transfer the funds directly from the sub-account to theseller's bank account. Alternatively, the payment processor server 160may transfer the funds into the general account, and then immediatelytransfer these funds into the seller's bank account. The latter methodmay be preferable so as to conceal the sub-account information fromoutside financial institutions such as the seller's bank. The lattermethod may also be preferable when sub-accounts are logical accounts orelectronic records. In such an instance, the payment processor server160 may perform the first transfer from the sub-account account into thegeneral account via an updating of the appropriate logical account orelectronic record, while performing the second transfer from the generalaccount into the seller's bank account via, for example, ACH.

In step S925, the payment processor server 160 initiates a disbursementof funds to the auction service's bank account for any fees associatedwith the auction service, and/or initiates a disbursement of funds toEPS's bank account for any fees associated with its escrow services. Thepayment processor server 160 may also disburse to itself the feesassociated with its own services. These disbursement(s) may occur in thesame manner as described above with respect to step S924, oralternatively may occur via any other transfer methodology establishedbetween the payment processor and the auction service and/or EPS.

At this stage, the balance of the sub-account should be zero. In StepS926, the payment processor server 160 closes the sub-account.

It will be appreciated that the auction transaction may alternatively oradditionally involve services or other contractual obligations insteadof goods, and the steps described in FIGS. 9A-9C may be modified asappropriate for confirming the receipt of such services or contractualobligations. For instance, if the auction involves a service or othercontractual obligation, steps S910-S917 may be skipped and stepsS918-S922 may alternatively correspond to the acceptance of the serviceor contractual obligation. Of course, even with goods, any type ofcondition may be alternatively used to trigger a timer and/or thedisbursement of funds. Examples include, but are not limited to,shipping, tracking, delivery confirmation, and delivery & inspectionclocks.

It will further be appreciated that EPS server 150 may alternativelyhave the ability to create, administer, and terminate sub-accounts,instead of payment processor server 160. For instance, EPS server 150may incorporate electronic records which uniquely identify eachtransaction and funds corresponding to the transaction, and theavailable balance for that transaction. In such an instance, paymentprocessor server 160 may operate the transfers between external accounts(e.g., ACH), while EPS server 150 provides the functionality for theadministration of sub-accounts.

It will even further be appreciated that the debit in steps S906-S908 isnot limited to a single buyer bank account, but may alternativelyconstitute multiple debits from multiple accounts affiliated with thebuyer and/or an associate of the buyer. That is, the sub-account may befunded by multiple funding sources. Similarly, it will be appreciatedthat the disbursement in steps S923 and S924 is not limited to a singleseller bank account, but may alternatively constitute multiple creditsto multiple accounts affiliated with the seller and/or an associate ofthe seller. That is, the sub-account funds may be disbursed to multiplefunding recipients.

FIG. 11 depicts various banking accounts that may be involved during theoperation of the invention. As seen in FIG. 11, a payment processorincludes a general escrow account 1100. The general escrow account 1100is used to facilitate the transfer of funds between the paymentprocessor and external banks. For instance, the payment processor mayincorporate a sub-account structure which lacks direct ACH accountaccess. In this case, the sub-accounts may simply be logical accountsmanaged by the payment processor. Fund transfers may then beaccomplished by a combination of an internal transfer between thegeneral escrow account 1100 and a sub-account, and a debit or creditbetween the general escrow account 1100 and an external account.

Three payment processor sub-accounts 1110-1112 are shown in FIG. 11.Sub-account 1110 is designated for auction #518473, a transactionbetween seller A and buyer X. Sub-account 1111 is designated for auction#518474, a transaction between seller A and buyer Y. Sub-account 1112 isdesignated for auction #518937, a transaction between seller B and buyerX.

Four external bank accounts 1120-1123 are also shown in FIG. 11. Bankaccount 1120 is located within bank #1, and belongs to seller A. Bankaccount 1121 is located within bank #2, and belongs to seller B. Bankaccount 1122 is located within bank #3, and belongs to buyer X. Bankaccount 1123 is located within bank #4, and belongs to buyer Y.

Funds are transferred via an ACH or wire transfer network 1130connecting the banks #1-#4 and the payment processor. Alternatively, itwill be appreciated that any other connection allowing for financialtransfer may be used instead of, or in addition to, the ACH or wiretransfer network.

FIG. 12 shows a first method of processing fund transfers whichincorporates a real-time approach and which may be utilized with theinvention including steps S905-S908, S920, and S923-S926. Using thismethod, fund transfers are initiated immediately upon receipt.

In this method, steps S1201-S1206 illustrate the debiting of the buyer'sfunds, while steps S1207-S1212 illustrate the disbursement of funds tothe seller.

In step S1201, the auction server 110 transmits winning bid informationof an auction to the EPS server 150. Step S1201 corresponds to step S905in FIG. 9A.

In step S1202, the auction server 110 immediately processes the winningbid information, generates a request to debit the funds from the buyer'saccount, and immediately sends the request to the payment processorserver 160. Step S1202 corresponds to step S906 in FIG. 9A.

In step S1203, the payment processor server 160 receives the request,and validates the buyer's bank account. This validation may includeinternal verifications such as a check on whether a line of business(LOB) exists. In step S1204, upon validation of the request, the paymentprocessor server 160 creates a sub-account for the transaction. StepsS1203 and S1204 correspond to step S907 in FIG. 9A.

As seen in FIG. 12, the results of these verifications are immediatelyreturned to the EPS server 150. The EPS server 150 receives thisinformation and consumes and reconciles the validation information,either instantaneously or periodically (e.g., every few hours). If thedebit request fails validation, the EPS server 150 notifies the auctionserver 110, who in turn notifies the buyer of such failure.

In step S1205, the payment processor server 160 initiates a debit fromthe buyer's bank account into a general account. In step S1206, thepayment processor server 160 transfers the debited funds into thesub-account. Steps S1205 and S1206 correspond to step S908 in FIG. 9A.

As already described above, the payment processor server 160 preferablydebits the funds into a general account and then transfers the fundsinto the sub-account. As previously mentioned, the latter method may bepreferable when sub-accounts are logical accounts or electronic records.In such an instance, the payment processor server 160 may perform thefirst transfer from the buyer's bank account into a general account via,for example, ACH, while performing the second transfer from the generalaccount into the sub-account via an updating of the appropriate logicalaccount or electronic record. However, it will be appreciated thatalternatively the payment processor server 160 may directly debit thefunds into the sub-account. In this case, steps S1205 and S1206 may becombined into such a single step.

In step S1207, the auction server 110 receives a notification of thebuyer's acceptance of the goods, and provides this information to theEPS server 150. Step S1207 corresponds to step S920 in FIG. 9C.

In step S1208, the EPS server 150, immediately after receiving thenotification from the auction server 110, sends a credit instruction tothe payment processor server 160. Step S1208 corresponds to step S923 inFIG. 9C.

In step S1209, the payment processor server 160 receives the request,and validates the seller's bank account. This validation may includeinternal verifications such as a check on whether a LOB exists, alongwith whether sufficient funds exist for the request.

As seen in FIG. 12, the results of these verifications are immediatelyreturned to the EPS server 150. If the credit request fails validation,the EPS server 150 notifies the auction server 110, who in turn notifiesthe seller of such failure.

In step S1210, upon validation of the request, the payment processorserver 160 transfers the appropriate funds from the sub-account to thegeneral account, and in step S1211, initiates a credit from the generalaccount to the seller's bank account. Steps S1209-S1211 correspond tostep S924 in FIG. 9C. If sub-accounts are logical accounts or electronicrecords, the payment processor server 160 may perform the first transferfrom the sub-account account into the general account via an updating ofthe appropriate logical account or electronic record, while performingthe second transfer from the general account into the seller's bankaccount via, for example, ACH.

As with the debit process, it will be appreciated that alternatively thepayment processor server 160 may directly credit the funds from thesub-account to the seller's bank account. In this case, steps S1210 andS1211 may be combined into such a single step.

It will also be appreciated that steps analogous to steps S1210 andS1211 may also be performed to initiate the disbursement of funds forpayment of auction, escrow, and/or other fees, which corresponds to stepS925 in FIG. 9C.

In step S1212, the payment processor server closes the sub-account ifall fund transfers for the auction have been completed. Step S1212corresponds to step S926 in FIG. 9C.

As described above, the real-time processing method involves theimmediate processing of sub-account activity, and the transfers offunds. Debit and credit transactions are processed immediately, and theresults of the transactions are immediately returned to the EPS server150 and/or the auction server 110.

The benefits of using this real-time processing method include a quickvalidation, so that any requests that fail the validation can promptlybe corrected and re-submitted. Effectively, auction participants areable to check the real-time status of their initial validation of theirpayment request. However, real-time processing is less efficient andinvolves increased overhead. Moreover, as validated requests areimmediately processed, any modifications in a request cannot beprocessed until the original request is first completed.

FIG. 13 shows a second method of processing fund transfers whichincorporates a batch approach and which may be utilized with theinvention including steps S905-S908, S920, and S923-S926. Using thismethod, fund transfers are initiated at the close of each business dayas a daily batch.

In this method, steps S1302, S1303, and S1307-S1310 illustrate thedebiting of buyer's funds, while steps S1304, S1305, and S1311-S1314illustrate the disbursement of funds to the seller.

In step S1301, at the beginning of a business day, the EPS server 150creates a blank list of transactions to be performed by the paymentprocessor server 160, including debit and credit requests andsub-account activity.

In step S1302, the auction server 110 transmits winning bid informationof a first auction (“auction #1”) to the EPS server 150. Step S1302corresponds to step S905 in FIG. 9A.

In step S1303, the EPS server 150 adds a debit request to the batchlist, but does not yet transmit any information to the payment processorserver 160.

In step S1304, the auction server 110 receives a notification of thebuyer's acceptance of the goods in a second auction (“auction #2”), andprovides this information to the EPS server 150. Step S1304 correspondsto step S920 in FIG. 9C.

In step S1305, the EPS server 150 adds a credit request to the batchlist, but does not yet transmit any information to the payment processorserver 160.

Based on shipping and inspection times, goods are ordinarily notdelivered and accepted until days after winning auction information istransmitted and buyer funds are debited. As such, steps S1304, S1305,and S1311-S1314 are described as relating to a second auction for adisbursement transaction in the second auction that is conducted on thesame day as the debit in the first auction. However, it will beappreciated that steps S1304, S1305, and S1311-S1314 are applicable tothe first auction if the goods are delivered, inspected, and accepted onthe same day.

In step S1306, at the close of the business day, the EPS server 150sends the batch list to the payment processor server 160. Thecombination of steps S1303 and S1306 corresponds to step S905 in FIG.9A, and the combination of steps S1305 and S1306 corresponds to stepS923 in FIG. 9C.

In step S1307, the payment processor server 160 validates the buyer'sbank account in auction #1. This validation may include internalverifications such as a check on whether a LOB exists. In step S1308,upon validation of the request, the payment processor server 160 createsa sub-account for the transaction. Steps S1307 and S1308 correspond tostep S907 in FIG. 9A.

As seen in FIG. 13, the results of these verifications are then returnedto the EPS server 150 at the close of the business day. The EPS server150 receives this information, and consumes and reconciles theaggregated information.

In step S1309, the payment processor server 160 initiates a debit fromthe buyer's bank account into a general account. In step S1310, thepayment processor server 160 transfers the debited funds into thesub-account. Steps S1309 and S1310 correspond to step S908 in FIG. 9A.

As already described above, the payment processor server 160 preferablydebits the funds into a general account and then transfers the fundsinto the sub-account. As previously mentioned, this method may bepreferable when sub-accounts are logical accounts or electronic records.In such an instance, the payment processor server 160 may perform thefirst transfer from the buyer's bank account into a general account via,for example, ACH, while performing the second transfer from the generalaccount into the sub-account via an updating of the appropriate logicalaccount or electronic record. However, it will be appreciated thatalternatively the payment processor server 160 may directly debit thefunds into the sub-account. In this case, steps S1309 and S1310 may becombined into such a single step.

In step S1311, the payment processor server 160 validates the seller'sbank account in auction #2. This validation may include internalverifications such as a check on whether a LOB exists, along withwhether sufficient funds exist for the request.

As seen in FIG. 13, the results of these verifications are returned tothe EPS server 150 at the close of the business day. The EPS server 150receives this information, and consumes and reconciles the aggregatedinformation. If a debit or credit request fails validation, the EPSserver 150 notifies the auction server 110, who in turn notifies therespective party of such failure.

In step S1312, upon validation of the request, the payment processorserver 160 transfers the appropriate funds from the sub-account to thegeneral account, and in step S1313, initiates a credit from the generalaccount to the seller's bank account. Steps S1311-S1313 correspond tostep S924 in FIG. 9C. If sub-accounts are logical accounts or electronicrecords, the payment processor server 160 may perform the first transferfrom the sub-account account into the general account via an updating ofthe appropriate logical account or electronic record, while performingthe second transfer from the general account into the seller's bankaccount via, for example, ACH.

As with the debit process, it will be appreciated that alternatively thepayment processor server 160 may directly credit the funds from thesub-account to the seller's bank account. In this case, steps S1312 andS1313 may be combined into such a single step.

It will also be appreciated that steps analogous to steps S1312 andS1313 may also be performed to initiate the disbursement of funds forpayment of auction, escrow, and/or other fees, which corresponds to stepS925 in FIG. 9C.

In step S1314, the payment processor server closes the sub-account ifall fund transfers for the auction have been completed. Step S1314corresponds to step S926 in FIG. 9C.

As described above, the batch processing method involves the holding ofsub-account activity and fund transfer requests until the end of thebusiness day.

The benefits of using this batch processing method include the reductionof overhead and more efficient processing of transfers. Additionally,modifications to requests may be applied throughout the business day,such that only the final modified request is processed at the end of theday. However, validations are not conducted until the end of the day,and any transaction that fails the validation is delayed until at leastthe next business day. As a result, the transfer of funds from buyer toseller may be delayed.

It will be appreciated that any period other than a business day mayalternatively be used, the period is not limited to even a dailyinterval, and that even when a daily interval is selected, the days mayalso include weekends and/or holidays.

It will further be appreciated that while the method of FIG. 13describes a single batch list containing both debit and credit requests,separate batch lists for debit requests and credit requests, or anyother division of requests are also within the scope of the invention.

FIG. 14 shows a third method of processing fund transfers whichincorporates a hybrid real-time/batch approach and which may be utilizedwith the invention including steps S905-S908, S920, and S923-S926. Usingthis method, validations are immediately performed on debit and creditrequests, but the requests are “held” until the end of the business daywhen they are “released” for actual processing.

In this method, steps S1402-S1405 and S1411-S1413 illustrate thedebiting of buyer's funds, while steps S1406-S1409 and S1414-S1416illustrate the disbursement of funds to the seller.

In step S1401, at the beginning of a business day, the EPS server 150creates a blank list of requests to be released by the payment processorserver 160, including debit and credit requests and sub-accountactivity.

In step S1402, the auction server 110 transmits winning bid informationof a first auction (“auction #1”) to the EPS server 150. Step S1402corresponds to step S905 in FIG. 9A.

In step S1403, the auction server 110 immediately sends a request to thepayment processor server 160 to validate the debit request.

In step S1404, the payment processor server 160 receives the request,and validates the buyer's bank account. This validation may includeinternal verifications such as a check on whether a LOB exists.

As seen in FIG. 14, the results of these verifications are immediatelyreturned to the EPS server 150.

In step S1405, the EPS server 150 receives the validation information.If the debit request is successfully validated, the EPS server 150 addsthe debit request to the release list. By adding the debit request tothe release list, the transaction is placed on hold until its release atthe close of the business day. The EPS server 150 also consumes andreconciles the validation information, either instantaneously orperiodically (e.g., every few hours). If the debit request failsvalidation, the EPS server 150 notifies the auction server 110, which inturn notifies the buyer of such failure.

In step S1406, the auction server 110 receives a notification of thebuyer's acceptance of the goods in a second auction (“auction #2”), andprovides this information to the EPS server 150. Step S1406 correspondsto step S920 in FIG. 9C.

In step S1407, the auction server 110 immediately sends a request to thepayment processor server 160 to validate the credit request.

In step S1408, the payment processor server 160 receives the request,and validates the seller's bank account. This validation may includeinternal verifications such as a check on whether a LOB exists, alongwith whether sufficient funds exist for the request.

As seen in FIG. 14, the results of these verifications are immediatelyreturned to the EPS server 150.

In step S1409, the EPS server 150 receives the validation information.If the credit request is successfully validated, the EPS server 150 addsthe credit request to the release list. By adding the credit request tothe release list, the transaction is placed on hold until its release atthe close of the business day. The EPS server 150 also consumes andreconciles the validation information, either instantaneously orperiodically (e.g., every few hours). If the credit request failsvalidation, the EPS server 150 notifies the auction server 110, which inturn notifies the seller of such failure.

Based on shipping and inspection times, goods are ordinarily notdelivered and accepted until days after winning auction information istransmitted and buyer funds are debited. As such, steps S1406, S1407,S1409, and S1414-S1416 are described as relating to a second auction fora disbursement transaction in the second auction that is conducted onthe same day as the debit in the first auction. However, it will beappreciated that steps S1406, S1407, S1409, and S1414-S1416 areapplicable to the first auction if the goods are delivered, inspected,and accepted on the same day.

In step S1410, at the close of the business day, the EPS server 150sends the release list to the payment processor server 160. Thecombination of steps S1405 and S1410 corresponds to step S905 in FIG.9A, and the combination of steps S1409 and S1410 corresponds to stepS923 in FIG. 9C.

In step S1411, the payment processor server 160 creates a sub-accountfor the transaction. Step S1404 and S1411 correspond to step S907 inFIG. 9A.

In step S1412, the payment processor server 160 initiates a debit fromthe buyer's bank account into a general account. In step S1413, thepayment processor server 160 transfers the debited funds into thesub-account. Steps S1412 and S1413 correspond to step S908 in FIG. 9A.

As already described above, the payment processor server 160 preferablydebits the funds into a general account and then transfers the fundsinto the sub-account. As previously mentioned, this method may bepreferable when sub-accounts are logical accounts or electronic records.In such an instance, the payment processor server 160 may perform thefirst transfer from the buyer's bank account into a general account via,for example, ACH, while performing the second transfer from the generalaccount into the sub-account via an updating of the appropriate logicalaccount or electronic record. However, it will be appreciated thatalternatively the payment processor server 160 may directly debit thefunds into the sub-account. In this case, steps S1412 and S1413 may becombined into such a single step.

In step S1414, the payment processor server 160 transfers theappropriate funds from the sub-account to the general account, and instep S1415, initiates a credit from the general account to the seller'sbank account. Steps S1408, S1414, and S1415 correspond to step S924 inFIG. 9C. If sub-accounts are logical accounts or electronic records, thepayment processor server 160 may perform the first transfer from thesub-account account into the general account via an updating of theappropriate logical account or electronic record, while performing thesecond transfer from the general account into the seller's bank accountvia, for example, ACH.

As with the debit process, it will be appreciated that alternatively thepayment processor server 160 may directly credit the funds from thesub-account to the seller's bank account. In this case, steps S1414 andS1415 may be combined into such a single step.

It will also be appreciated that steps analogous to steps S1414 andS1415 may also be performed to initiate the disbursement of funds forpayment of auction, escrow, and/or other fees, which corresponds to stepS925 in FIG. 9C.

In step S1416, the payment processor server closes the sub-account ifall fund transfers for the auction have been completed. Step S1416corresponds to step S926 in FIG. 9C.

As with the batch method of FIG. 13, it will be appreciated that anyperiod other than a business day may alternatively be used for a releaseperiod, the period is not limited to even a daily interval, and thateven when a daily interval is selected, the days may also includeweekends and/or holidays.

It will further be appreciated that while the method of FIG. 14describes a single release list containing both debit and creditrequests, separate release lists for debit requests and credit requests,or any other division of requests are also within the scope of theinvention.

In the methods described in FIGS. 12-14, it will be appreciated that acredit request may be alternatively triggered by the expiration of thetimer according to step S922, instead of by a notification of anacceptance of goods.

FIG. 15 shows an example release file 1500 that may be used inconnection with the hybrid real-time/batch approach described in FIG. 14in storing the release list. The example references the transactionsdescribed in FIG. 11.

The first entry in release file 1500 corresponds to a release of a debitrequest for auction #518473. This request instructs the paymentprocessor server 160 to create Sub-account #1, debit $5,000 from buyerX's bank account via ACH pull into its general account, and transfer the$5,000 into Sub-account #1.

The second entry in release file 1500 corresponds to a release of adebit request for auction #518474. This request instructs the paymentprocessor server 160 to create Sub-account #2, debit $7,000 from buyerY's bank account via ACH pull into its general account, and transfer the$7,000 into Sub-account #2.

The third entry in release file 1500 corresponds to a release of acredit request for auction #518937. This request instructs the paymentprocessor server 160 to disburse $1000 from Sub-account #3 into sellerB's bank account.

The fourth entry in release file 1500 corresponds to a release ofanother credit request for auction #518937. This request instructs thepayment processor server 160 to disburse $100 from Sub-account #3 intothe auction server's accounts-receivable bank account, as payment ofservice fees for the auction.

It will be appreciated that other debit and credit transactionsinvolving buyer X, buyer Y, seller A, seller B, the auction service,EPS, and other entities may exist, but in this example, may be requestedon a day other than this particular business day.

It will also be appreciated that the requests may already be stored onthe payment processor server 160 during the validation process, and therelease file 1500 may simply refer to an identification of the requeststored on the payment processor server 160.

The invention thus far has been described with respect with an auction,and specifically a reverse auction. However, the invention is notlimited thereto.

FIG. 16 shows an online system 1600 that may carry out features inaccordance with another aspect of the present invention. The samecomponent elements as those already described are designated by the samereference numerals and their description is omitted and differentoperations will be described here.

This aspect of the invention differs from the first aspect of theinvention, in that an online business 1610 is provided in the system1600 instead of the auction server 110. Online business 1610 isconnected to network 120 via a network link 1621. It will be appreciatedthat online business 1610, EPS server 150, and payment processor server160 may alternatively be connected through dedicated and/or privatenetwork links or other methods of information exchange.

It will be appreciated that online business 1610 may be any service thatmanages a transaction between a payor and a payee. Examples oftransactions include, but are not limited to, auctions, sales of goodsand services, contractual obligations, or any other type of transaction.It will also be appreciated that EPS server 150 may be capable ofoperating with multiple online businesses 1610 (e.g., differenttransaction/sales/auction web sites).

The system 1600 also includes at least one payee device 1630 and atleast one payor device 1640. Payee device 1630 is connected to network120 via a network link 1631, and payor device 1640 is connected tonetwork 120 via a network link 1641. In a preferred embodiment, payeedevice 1630 and payor device 1640 are personal computers. However, itwill be appreciated that the devices may alternatively include cellulartelephones (e.g., smartphones), tablets, terminals, or any other devicescapable of submitting electronic information to the system 1600.

Payee device 1630 is operated by a payee desiring to receive a paymentfrom a payor. The payee may be an individual or other entity (e.g.,corporate or government).

Payor device 1640 is operated by the payor desiring to provide thepayment to the payee. The payor may be an individual or other entity(e.g., corporate or government).

It will be understood that system 1600 may include multiple payeedevices 1630 and multiple payor devices 1640, each connected to network120. It will also be appreciated that any payee device 1630 and/or payordevice 1640 may communicate with the online business 1610 via a webbrowser, dedicated software, text messaging, or any other form of datacommunication.

FIG. 17 shows various hardware features of online business 1610. Onlinebusiness 1610 includes a CPU 1711, memory 1712 (such as RAM), datastorage 1713 (such as a hard disk or solid state drive), and a networkinterface 1714.

CPU 1711 processes instructions stored in memory 1712, in accordancewith operating system and software stored in data storage 1713 forexecution by online business 1610. Data storage 1713 also stores datafor the client software for executing transactions.

Network interface 1714 enables online business 1610 to communicate withnetwork 120 over network link 1621.

FIG. 18 shows the software modules for software executed on onlinebusiness 1610. Online business 1610 executes a transaction processingmodule 1810. Transaction processing module 1810 may include software forconducting a transaction, such as accepting a transaction request,initiating a transaction, finalizing a transaction, and notifyingcorresponding parties of the transaction status and activities.Transaction processing module 1810 may optionally coordinate theexchange of items and funds between the payor and payee.

Online business 1610 also executes an EPS interface module 1820. EPSinterface module 1820 exchanges data with EPS server 150 using networkinterface 1714.

Online business 1610 further executes a user authentication module 1830.User authentication module 1830 authenticates the operators of payeedevices 1630 and payor devices 1640. User authentication module 1830thus confirms the identity of the payees and payors.

FIGS. 19A-19C show a method of operating the online business 1610, EPSserver 150, and payment processor server 160 in accordance with a secondembodiment of the invention. FIG. 10 still graphically represents theexecution of the method of FIGS. 19A-19C, with the respective stepsperformed by the payor, the payee, EPS, the online business, and thepayment processor.

In step S1901, the online business 1610 captures payor and payee bankinginformation. The online business 1610 forwards the banking informationto the EPS server 150, which in turn forwards such information to thepayment processor server 160.

In step S1902, the payment processor server 160 conducts validation andsecurity checks on the received banking information. The paymentprocessor server 160 transmits the results of these checks to the EPSserver 150, which in turn forwards the information to the onlinebusiness 1610. It will be appreciated that the online business 1610 maybe configured so as to prevent payors and payees from participating in atransaction until their banking information has been approved. It willbe appreciated that the EPS server 150 may itself be capable ofconducting the validation and security checks, and in such an instance,the EPS server 150 will perform such checks without involving thepayment processor server 160.

In step S1903, the online business 1610 initiates the transaction. Itwill be appreciated that the particular features of this step willdepend on the specific transaction involved.

In step S1904, the online business 1610 finalizes the transaction.

In step S1905, the online business 1610 transmits the transactioninformation to the EPS server 150.

In step S1906, the EPS server 150 sends an instruction to the paymentprocessor server 160 with information regarding the payor and thetransaction. This information includes at least the payor's bank accountinformation, along with the amounts of the transaction payment and feesfor debit from the payor's account. Alternatively, if the payor's bankaccount information is pre-stored and is identifiable by the EPS server150 and the payment processor server 160 using another identifier, thatother identifier may be used instead.

In step S1907, the payment processor server 160 creates a unique anddiscrete financial account affiliated with the transaction. This uniquefinancial account is also referred to herein as a sub-account. Thissub-account will subsequently store the funds debited from the payor'sbank account, and is specific to the transaction. That is, thissub-account is different from all remaining sub-accounts, even in thecase where the payee of a first transaction is the same as the payee ofa second transaction, or where the payor of a first transaction is thesame as the payor of a second transaction.

In step S1908, the payment processor server 160 initiates a debit fromthe payor's bank account, for the amount of the transaction and thefees, according to the information received in step S1906. The paymentprocessor server 160 stores these debited funds in the sub-accountcreated in step S1907. It will be appreciated that this debit may occurin at least one of two different techniques. First, the paymentprocessor server 160 may transfer received funds directly into thesub-account. Alternatively, the payment processor server 160 maytransfer received funds into a general account, and then immediatelytransfer these funds into the sub-account. The latter method may bepreferable so as to conceal the sub-account information from outsidefinancial institutions such as the payor's bank. The latter method mayalso be preferable when sub-accounts are logical accounts or electronicrecords. In such an instance, the payment processor server 160 mayperform the first transfer from the payor's bank account into a generalaccount via, for example, ACH, while performing the second transfer fromthe general account into the sub-account via an updating of theappropriate logical account or electronic record. The payment processorserver 160 may notify the EPS server 150 once the debit has beencompleted and the funds are stored in the sub-account.

In step S1909, the EPS server 150 sends a notice to the online business1610 that the debit has been completed.

In step S1910, the online business 1610 sends a notice to the payee toship the transaction goods to the payor.

In step S1911, the payee employs a shipping service to ship thetransaction goods to the payor.

In step S1912, the shipping service delivers the transaction goods tothe payor.

In step S1913, the payee provides proof of delivery to the onlinebusiness 1610.

In step S1914, the online business 1610 transmits the payee's proof ofdelivery to the EPS server 150.

In step S1915, the EPS server 150 sends a request to the online business1610 to confirm with the payor that the goods were delivered.

In step S1916, the online business 1610 sends a notice to the payor,requesting that the payor confirm delivery of the goods.

In step S1917, the payor confirms the receipt of the transaction goods,by responding to the notice sent by the online business 1610 in stepS1916.

In step S1918, the EPS server 150 starts a timer according to apredetermined time period. The predetermined time period is the periodprovided to the payor to inspect the delivered goods and raise anobjection as to the shipment. For instance, the payor may object thatcertain transaction goods are missing from the shipment. Or, the payormay object that the delivered goods are defective or inconsistent with adescription of these goods provided by the payee during the pendency ofthe transaction.

In step S1919, the EPS server 150 awaits an acceptance or an objectionfrom the payor. If the payor accepts the goods, the EPS server 150proceeds to step S1920. If the payor objects to the goods, the EPSserver 150 proceeds to step S1921. If the payor has not provided eitheran acceptance or an objection, the EPS server 150 proceeds to stepS1922.

In step S1920, a payor acceptance causes the online business 1610 totransmit such acceptance information to the EPS server 150, and the EPSserver 150 receives such information.

In step S1921, an objection lodged by the payor as to the transactiongoods causes a dispute resolution proceeding and/or an arbitrationproceeding to be commenced to resolve the dispute. Meanwhile, thepayment processor server 160 maintains the funds stored in thesub-account pending a dispute resolution or an arbitration decision. Itwill be appreciated that the payor or payee may initiate disputeresolution and/or arbitration via any acceptable method. For instance,the payor may initiate the dispute resolution and/or arbitration via theonline business 1610, which in turn notifies the EPS server 150 of thisstatus. Alternatively, the payor may initiate the dispute resolutionand/or arbitration directly via the EPS server 150 or through any othermeans.

In step S1922, the EPS server 150 determines whether the timer set instep S1918 has expired. If the timer has not expired, the EPS server 150returns to step S1919. If the timer has expired, the EPS server 150proceeds to step S1923.

It will be appreciated that steps S1918-S1922 may be optional steps inaccordance with a desired operation of the system, and that the systemmay be operated such that delivery confirmation by the payor and/orpayee is a sufficient condition for disbursement of funds.

In step S1923, the EPS server 150 sends a credit instruction to thepayment processor server 160 to disburse the funds in the sub-account.

In step S1924, the payment processor server 160 initiates a disbursementof funds to the payee's bank account. These funds represent the paymentfor the transaction goods, and customarily will equal the amount debitedin step S1908, less any fees that the online business, the escrowpayment service, and/or the payment processor deducts for itscontributed services in the transaction. The disbursement may occur in asimilar manner to the transfer(s) in step S1908. That is, the paymentprocessor server 160 may transfer the funds directly from thesub-account to the payee's bank account. Alternatively, the paymentprocessor server 160 may transfer the funds into the general account,and then immediately transfer these funds into the payee's bank account.The latter method may be preferable so as to conceal the sub-accountinformation from outside financial institutions such as the payee'sbank. The latter method may also be preferable when sub-accounts arelogical accounts or electronic records. In such an instance, the paymentprocessor server 160 may perform the first transfer from the sub-accountaccount into the general account via an updating of the appropriatelogical account or electronic record, while performing the secondtransfer from the general account into the payee's bank account via, forexample, ACH.

In step S1925, the payment processor server 160 initiates a disbursementof funds to the online business' bank account for any fees associatedwith the transaction service, and/or initiates a disbursement of fundsto EPS's bank account for any fees associated with its escrow services.The payment processor server 160 may also disburse to itself the feesassociated with its own services. These disbursement(s) may occur in thesame manner as described above with respect to step S1924, oralternatively may occur via any other transfer methodology establishedbetween the payment processor and the online business and/or EPS.

At this stage, the balance of the sub-account should be zero. In StepS1926, the payment processor server 160 closes the sub-account.

It will be appreciated that the transaction may alternatively oradditionally involve services or other contractual obligations insteadof goods, and the steps described in FIGS. 19A-19C may be modified asappropriate for confirming the receipt of such services or contractualobligations. For instance, if the transaction involves a service orother contractual obligation, steps S1910-S1917 may be skipped and stepsS1918-S1922 may alternatively correspond to the acceptance of theservice or contractual obligation. Of course, even with goods, any typeof condition may be alternatively used to trigger a timer and/or thedisbursement of funds. Examples include, but are not limited to,shipping, tracking, delivery confirmation, and delivery & inspectionclocks.

It will further be appreciated that EPS server 150 may alternativelyhave the ability to create, administer, and terminate sub-accounts,instead of payment processor server 160. For instance, EPS server 150may incorporate electronic records which uniquely identify eachtransaction and funds corresponding to the transaction, and theavailable balance for that transaction. In such an instance, paymentprocessor server 160 may operate the transfers between external accounts(e.g., ACH), while EPS server 150 provides the functionality for theadministration of sub-accounts.

It will even further be appreciated that the debit in steps S1906-S1908is not limited to a single payor bank account, but may alternativelyconstitute multiple debits from multiple accounts affiliated with thepayor and/or an associate of the payor. That is, the sub-account may befunded by multiple funding sources. Similarly, it will be appreciatedthat the disbursement in steps S1923 and S1924 is not limited to asingle payee bank account, but may alternatively constitute multiplecredits to multiple accounts affiliated with the payee and/or anassociate of the payee. That is, the sub-account funds may be disbursedto multiple funding recipients.

It will also be appreciated that debit and credit requests may beprocessed in real-time, batch, or hybrid real-time/batch as explainedabove with reference to FIGS. 12-14.

The invention thus far has been described with respect with an auctionserver or an online business that handles a transaction. However, theinvention is not limited thereto.

FIG. 20 shows an online system 2000 that may carry out features inaccordance with yet another aspect of the present invention. The samecomponent elements as those already described are designated by the samereference numerals and their description is omitted and differentoperations will be described here.

This aspect of the invention differs from the first and second aspectsof the invention, in that a payee and a payor directly coordinate withEPS server 150 to oversee a transfer of funds, without an interveningentity such as the auction server 110 or the online business 1610. Insuch an instance, the transaction details may have already beenfinalized between the payor and the payee, and all that remains is thetransfer of payment and corresponding goods, services, or othercontractual obligations. It will be understood that the invention mayalso be used to transfer payment from the payor to the payee without anycorresponding obligation by the payee.

The system 2000 also includes at least one payee device 2030 and atleast one payor device 2040. Payee device 2030 is connected to network120 via a network link 2031, and payor device 2040 is connected tonetwork 120 via a network link 2041. In a preferred embodiment, payeedevice 2030 and payor device 2040 are personal computers. However, itwill be appreciated that the devices may alternatively include cellulartelephones (e.g., smartphones), tablets, terminals, or any other devicescapable of submitting electronic information to the system 2000.

Payee device 2030 is operated by a payee desiring to receive a paymentfrom a payor. The payee may be an individual or other entity (e.g.,corporate or government).

Payor device 2040 is operated by the payor desiring to provide thepayment to the payee. The payor may be an individual or other entity(e.g., corporate or government).

It will be understood that system 2000 may include multiple payeedevices 2030 and multiple payor devices 2040, each connected to network120. It will also be appreciated that any payee device 2030 and/or payordevice 2040 may communicate with the EPS server 150 via a web browser,dedicated software, text messaging, or any other form of datacommunication.

FIGS. 21A-21B show a method of operating the EPS server 150 and paymentprocessor server 160 in accordance with a third embodiment of theinvention. FIG. 22 is a graphical representation of the execution of themethod of FIGS. 21A-21B, with the respective steps performed by thepayor, the payee, EPS, and the payment processor.

In step S2101, the EPS server 150 captures payor and payee bankinginformation. The EPS server 150 forwards such information to the paymentprocessor server 160.

In step S2102, the payment processor server 160 conducts validation andsecurity checks on the received banking information. The paymentprocessor server 160 transmits the results of these checks to the EPSserver 150. It will be appreciated that the EPS server 150 may beconfigured so as to prevent payors and payees from participating in atransaction until their banking information has been approved. It willbe appreciated that the EPS server 150 may itself be capable ofconducting the validation and security checks, and in such an instance,the EPS server 150 will perform such checks without involving thepayment processor server 160.

In step S2103, the EPS server 150 sends an instruction to the paymentprocessor server 160 with information regarding the payor and thetransaction. This information includes at least the payor's bank accountinformation, along with the amounts of the transaction payment and feesfor debit from the payor's account. Alternatively, if the payor's bankaccount information is pre-stored and is identifiable by the EPS server150 and the payment processor server 160 using another identifier, thatother identifier may be used instead.

In step S2104, the payment processor server 160 creates a unique anddiscrete financial account affiliated with the transaction. This uniquefinancial account is also referred to herein as a sub-account. Thissub-account will subsequently store the funds debited from the payor'sbank account, and is specific to the transaction. That is, thissub-account is different from all remaining sub-accounts, even in thecase where the payee of a first transaction is the same as the payee ofa second transaction, or where the payor of a first transaction is thesame as the payor of a second transaction.

In step S2105, the payment processor server 160 initiates a debit fromthe payor's bank account, for the amount of the transaction and thefees, according to the information received in step S2103. The paymentprocessor server 160 stores these debited funds in the sub-accountcreated in step S2104. It will be appreciated that this debit may occurin at least one of two different techniques. First, the paymentprocessor server 160 may transfer received funds directly into thesub-account. Alternatively, the payment processor server 160 maytransfer received funds into a general account, and then immediatelytransfer these funds into the sub-account. The latter method may bepreferable so as to conceal the sub-account information from outsidefinancial institutions such as the payor's bank. The latter method mayalso be preferable when sub-accounts are logical accounts or electronicrecords. In such an instance, the payment processor server 160 mayperform the first transfer from the payor's bank account into a generalaccount via, for example, ACH, while performing the second transfer fromthe general account into the sub-account via an updating of theappropriate logical account or electronic record. The payment processorserver 160 may notify the EPS server 150 once the debit has beencompleted and the funds are stored in the sub-account.

In step S2106, the EPS server 150 sends a notice to the payee to shipthe transaction goods to the payor.

In step S2107, the payee employs a shipping service to ship thetransaction goods to the payor.

In step S2108, the shipping service delivers the transaction goods tothe payor.

In step S2109, the payee provides proof of delivery to the EPS server150.

In step S2110, the EPS server 150 sends a notice to the payor,requesting that the payor confirm delivery of the goods.

In step S2111, the payor confirms the receipt of the transaction goods,by responding to the notice sent by the EPS server 150 in step S2110.

In step S2112, the EPS server 150 starts a timer according to apredetermined time period. The predetermined time period is the periodprovided to the payor to inspect the delivered goods and raise anobjection as to the shipment. For instance, the payor may object thatcertain transaction goods are missing from the shipment. Or, the payormay object that the delivered goods are defective or inconsistent with adescription of these goods provided by the payee during the pendency ofthe transaction.

In step S2113, the EPS server 150 awaits an acceptance or an objectionfrom the payor. If the payor accepts the goods, the EPS server 150proceeds to step S2116. If the payor objects to the goods, the EPSserver 150 proceeds to step S2114. If the payor has not provided eitheran acceptance or an objection, the EPS server 150 proceeds to stepS2115.

In step S2114, an objection lodged by the payor as to the transactiongoods causes a dispute resolution proceeding and/or an arbitrationproceeding to be commenced to resolve the dispute. Meanwhile, thepayment processor server 160 maintains the funds stored in thesub-account pending a dispute resolution or an arbitration decision. Itwill be appreciated that the payor or payee may initiate disputeresolution and/or arbitration via any acceptable method. For instance,the payor may initiate the dispute resolution and/or arbitration via theEPS server 150.

In step S2115, the EPS server 150 determines whether the timer set instep S2112 has expired. If the timer has not expired, the EPS server 150returns to step S2113. If the timer has expired, the EPS server 150proceeds to step S2116.

It will be appreciated that steps S2112-S2115 may be optional steps inaccordance with a desired operation of the system, and that the systemmay be operated such that delivery confirmation by the payor and/orpayee is a sufficient condition for disbursement of funds.

In step S2116, the EPS server 150 sends a credit instruction to thepayment processor server 160 to disburse the funds in the sub-account.

In step S2117, the payment processor server 160 initiates a disbursementof funds to the payee's bank account. These funds represent the paymentfor the transaction goods, and customarily will equal the amount debitedin step S2105, less any fees that the escrow payment service and/or thepayment processor deducts for its contributed services in thetransaction. The disbursement may occur in a similar manner to thetransfer(s) in step S2105. That is, the payment processor server 160 maytransfer the funds directly from the sub-account to the payee's bankaccount. Alternatively, the payment processor server 160 may transferthe funds into the general account, and then immediately transfer thesefunds into the payee's bank account. The latter method may be preferableso as to conceal the sub-account information from outside financialinstitutions such as the payee's bank. The latter method may also bepreferable when sub-accounts are logical accounts or electronic records.In such an instance, the payment processor server 160 may perform thefirst transfer from the sub-account account into the general account viaan updating of the appropriate logical account or electronic record,while performing the second transfer from the general account into thepayee's bank account via, for example, ACH.

In step S2118, the payment processor server 160 initiates a disbursementof funds to EPS's bank account for any fees associated with its escrowservices. The payment processor server 160 may also disburse to itselfthe fees associated with its own services. These disbursement(s) mayoccur in the same manner as described above with respect to step S2117,or alternatively may occur via any other transfer methodologyestablished between the payment processor and EPS.

At this stage, the balance of the sub-account should be zero. In StepS2119, the payment processor server 160 closes the sub-account.

It will be appreciated that the transaction may alternatively oradditionally involve services or other contractual obligations insteadof goods, and the steps described in FIGS. 21A-21C may be modified asappropriate for confirming the receipt of such services or contractualobligations. For instance, if the transaction involves a service orother contractual obligation, steps S2106-S2111 may be skipped and stepsS2112-S2115 may alternatively correspond to the acceptance of theservice or contractual obligation. Of course, even with goods, any typeof condition may be alternatively used to trigger a timer and/or thedisbursement of funds. Examples include, but are not limited to,shipping, tracking, delivery confirmation, and delivery & inspectionclocks.

It will further be appreciated that EPS server 150 may alternativelyhave the ability to create, administer, and terminate sub-accounts,instead of payment processor server 160. For instance, EPS server 150may incorporate electronic records which uniquely identify eachtransaction and funds corresponding to the transaction, and theavailable balance for that transaction. In such an instance, paymentprocessor server 160 may operate the transfers between external accounts(e.g., ACH), while EPS server 150 provides the functionality for theadministration of sub-accounts.

It will even further be appreciated that the debit in steps S2103-S2105is not limited to a single payor bank account, but may alternativelyconstitute multiple debits from multiple accounts affiliated with thepayor and/or an associate of the payor. That is, the sub-account may befunded by multiple funding sources. Similarly, it will be appreciatedthat the disbursement in steps S2116 and S2117 is not limited to asingle payee bank account, but may alternatively constitute multiplecredits to multiple accounts affiliated with the payee and/or anassociate of the payee. That is, the sub-account funds may be disbursedto multiple funding recipients.

It will also be appreciated that debit and credit requests may beprocessed in real-time, batch, or hybrid real-time/batch as explainedabove with reference to FIGS. 12-14.

In the foregoing description, example aspects of the present inventionare described with reference to specific example embodiments. Despitethese specific embodiments, many additional modifications and variationswould be apparent to those skilled in the art. Thus, it is to beunderstood that example embodiments of the invention may be practiced ina manner other than those specifically described. Accordingly, thespecification is to be regarded in an illustrative rather thanrestrictive fashion. It will be evident that modifications and changesmay be made thereto without departing from the broader spirit and scope.For instance, it will be appreciated that while the example aspects ofthe present invention generally involve online transactions, theinvention is not limited thereto, but also covers offline or any otherform of transaction.

Similarly, it should be understood that the figures are presented solelyfor example purposes. The architecture of the example embodimentspresented herein is sufficiently flexible and configurable such that itmay be practiced in ways other than that shown in the accompanyingfigures.

Furthermore, the purpose of the foregoing abstract is to enable the U.S.Patent and Trademark Office, the general public, and scientists,engineers, and practitioners in the art who are unfamiliar with patentor legal terms or phrases, to quickly determine from a cursoryinspection the nature and essence of the technical disclosure of theapplication. The abstract is not intended to limit the scope of thepresent invention in any way. It is also to be understood that theprocesses recited in the claims need not be performed in the orderpresented.

What is claimed is:
 1. A method of coordinating payment between a payorand a payee of a transaction for a contractual obligation, comprising:electronically receiving bank account information from an online entityadministering the transaction, the bank account information includinginformation on (1) a payor bank account corresponding to the payor, and(2) a payee bank account corresponding to the payee; electronicallyreceiving transaction information from the online entity, thetransaction information including a payment amount to be paid by thepayor to the payee for the contractual obligation; electronicallytransmitting a debit request to a payment processor, the debit requestincluding instructions to (1) create a discrete financial accountspecific to the transaction, (2) debit, from the payor bank account, adebit amount equal to or greater than the payment amount, (3) transferthe debit amount to the discrete financial account, and (4) hold thedebit amount in the discrete financial account; and electronicallytransmitting, after a confirmation that the contractual obligation hasbeen at least partially satisfied, a credit request to the paymentprocessor, the credit request including instructions to (1) transfer acredit amount from the discrete financial account, and (2) credit, tothe payee bank account, the payment amount, wherein said bank accountinformation electronic receiving step, said transaction informationelectronic receiving step, said debit request electronic transmittingstep, and said credit request electronic transmitting step areimplemented using at least one processor and at least one memory.
 2. Amethod according to claim 1, wherein said bank account informationelectronic receiving step is performed prior to the payor and the payeecompleting negotiation of the transaction, and wherein said transactioninformation electronic receiving step is performed after the payor andthe payee complete negotiation of the transaction.
 3. A method accordingto claim 1, wherein the online entity is an online auction service.
 4. Amethod according to claim 1, wherein the contractual obligation is adelivery of a good or a completion of a service.
 5. A method accordingto claim 1, further comprising: electronically transmitting a requestfor conducting a security check on the payee; and electronicallyreceiving the results of the security check.
 6. A method according toclaim 1, further comprising: electronically transmitting a request forconducting a security check on the payor; and electronically receivingthe results of the security check.
 7. A method according to claim 1,wherein said credit request electronically transmitting step isperformed only after at least one release condition is satisfied.
 8. Amethod according to claim 7, wherein at least one release conditionincludes a confirmation that the payee accepts that the contractualobligation has been fully satisfied.
 9. A method according to claim 7,further comprising: electronically initiating a timer, after theconfirmation that the contractual obligation has been at least partiallysatisfied, wherein the at least one release condition includes (1) anexpiration of the timer, and (2) a confirmation that the payee acceptsthat the contractual obligation has been fully satisfied.
 10. A methodaccording to claim 9, wherein the payment processor continues to holdthe debit amount upon a confirmation that the payee has rejected thecontractual obligation as not being fully satisfied.
 11. A methodaccording to claim 1, further comprising: electronically transmitting asecond credit request to the payment processor, the second creditrequest including instructions to (1) transfer a transaction fee amountfrom the discrete financial account, and (2) credit, to atransaction-fee bank account, the transaction fee amount.
 12. A methodaccording to claim 11, wherein the transaction fee corresponding to thetransaction fee amount is an online entity transaction fee, and whereinthe transaction-fee bank account is associated with the online entity.13. A method according to claim 11, wherein the transaction feecorresponding to the transaction fee amount is an escrow servicetransaction fee, and wherein the transaction-fee bank account isassociated with the escrow service.
 14. A method according to claim 1,wherein the transmitting in said debit request electronic transmittingstep and said credit request electronic transmitting step is performedin real-time.
 15. A method according to claim 1, wherein thetransmitting in said debit request electronic transmitting step and saidcredit request electronic transmitting step is performed as a periodictransmission of a batch of debit requests and credit requests.
 16. Amethod according to claim 1, said debit request electronic transmittingstep includes: electronically creating a release list of requests torelease, if a release list does not already exist; electronicallytransmitting a validation request of the debit request to the paymentprocessor; electronically adding the debit request to the release list,after receiving a confirmation that the debit request is valid;electronically transmitting the release list to the payment processor;and discarding the release list.
 17. A method according to claim 16,wherein said release list electronic creating step occurs at thebeginning of a business day, wherein said validation request electronictransmitting step occurs upon the receiving of transaction informationfrom the online entity, and wherein said release list electronictransmitting step occurs at the end of the business day.
 18. A methodaccording to claim 1, said credit request electronic transmitting stepincludes: electronically creating a release list of requests to release,if a release list does not already exist; electronically transmitting avalidation request of the credit request to the payment processor;electronically adding the credit request to the release list, afterreceiving a confirmation that the credit request is valid;electronically transmitting the release list to the payment processor;and discarding the release list.
 19. A method according to claim 18,wherein said release list electronic creating step occurs at thebeginning of a business day, wherein said validation request electronictransmitting step occurs upon the receiving of transaction informationfrom the online entity, and wherein said release list electronictransmitting step occurs at the end of the business day.
 20. A methodaccording to claim 16, wherein the release list in said debit requestelectronic transmitting step is a debit release list, and wherein saidcredit request electronic transmitting step includes: electronicallycreating a credit release list of requests to release, if a creditrelease list does not already exist, the credit release list beingdifferent from the debit release list; electronically transmitting avalidation request of the credit request to the payment processor;electronically adding the credit request to the credit release list,after receiving a confirmation that the credit request is valid;electronically transmitting the credit release list to the paymentprocessor; and discarding the credit release list.
 21. A methodaccording to claim 1, wherein the payment processor closes the discretefinancial account upon completion of all payments for the transaction.22. A method of coordinating a plurality of payments, each paymentcorresponding to a transaction between a payor and a payee for acontractual obligation, comprising: electronically receiving, for eachof the transactions, bank account information from an online entityadministering the transaction, the bank account information includinginformation on (1) a payor bank account corresponding to the respectivepayor, and (2) a payee bank account corresponding to the respectivepayee; electronically receiving, for each transaction, transactioninformation from the online entity, the transaction informationincluding a payment amount to be paid by the respective payor to therespective payee for the respective contractual obligation;electronically transmitting, for each of the transactions, a debitrequest to a payment processor, the debit request including instructionsto (1) create a discrete financial account specific to the transaction,(2) debit, from the respective payor bank account, a debit amount equalto or greater than the respective payment amount, (3) transfer the debitamount to the discrete financial account, and (4) hold the debit amountin the discrete financial account; and electronically transmitting, foreach of the transactions and after confirmation that the contractualobligation has been at least partially satisfied, a credit request tothe payment processor, the credit request including instructions to (1)transfer a credit amount from the respective discrete financial account,and (2) credit, to the respective payee bank account, the respectivepayment amount, wherein said bank account information electronicreceiving step, said transaction information electronic receiving step,said debit request electronic transmitting step, and said credit requestelectronic transmitting step are implemented using at least oneprocessor and at least one memory.
 23. A method according to claim 22,wherein said bank account information electronic receiving step isperformed prior to each respective payor and each respective payeecompleting negotiation of the respective transaction, and wherein saidtransaction information electronic receiving step is performed aftereach respective payor and each respective payee complete negotiation ofthe respective transaction.
 24. A method according to claim 22, whereinthe online entity is an online auction service.
 25. A method accordingto claim 22, wherein the contractual obligation is a delivery of a goodor a completion of a service.
 26. A method according to claim 22,further comprising: electronically transmitting a request for conductinga security check on each payee; and electronically receiving the resultsof the security check.
 27. A method according to claim 22, furthercomprising: electronically transmitting a request for conducting asecurity check on each payor; and electronically receiving the resultsof the security check.
 28. A method according to claim 22, wherein saidcredit request electronically transmitting step for a respectivetransaction is performed only after at least one release condition issatisfied.
 29. A method according to claim 28, wherein at least onerelease condition includes a confirmation that the respective payoraccepts that the contractual obligation has been fully satisfied.
 30. Amethod according to claim 28, further comprising: electronicallyinitiating a timer for each of the transactions, after the confirmationthat the contractual obligation has been at least partially satisfied,wherein the at least one release condition includes (1) an expiration ofthe timer, and (2) a confirmation that the respective payor accepts thatthe contractual obligation has been fully satisfied.
 31. A methodaccording to claim 30, wherein the payment processor continues to holdthe debit amount upon a confirmation that the respective payor hasrejected the contractual obligation as not being fully satisfied.
 32. Amethod according to claim 22, further comprising: electronicallytransmitting, for each of the transactions, a second credit request tothe payment processor, the second credit request including instructionsto (1) transfer a respective transaction fee amount from the respectivediscrete financial account, and (2) credit, to a transaction-fee bankaccount, the respective transaction fee amount.
 33. A method accordingto claim 32, wherein the transaction fee corresponding to the respectivetransaction fee amount is an online entity transaction fee, and whereinthe transaction-fee bank account is associated with the online entity.34. A method according to claim 32, wherein the transaction feecorresponding to the respective transaction fee amount is an escrowservice transaction fee, and wherein the transaction-fee bank account isassociated with the escrow service.
 35. A method according to claim 22,wherein the transmitting in said debit request electronic transmittingstep and said credit request electronic transmitting step is performedin real-time.
 36. A method according to claim 22, wherein thetransmitting in said debit request electronic transmitting step and saidcredit request electronic transmitting step is performed as a periodictransmission of a batch of debit requests and credit requests.
 37. Amethod according to claim 22, said debit request electronic transmittingstep includes: electronically creating a release list of requests torelease, if a release list does not already exist; electronicallytransmitting a validation request of the debit request to the paymentprocessor; electronically adding the debit request to the release list,after receiving a confirmation that the debit request is valid;electronically transmitting the release list to the payment processor;and discarding the release list.
 38. A method according to claim 37,wherein said release list electronic creating step occurs at thebeginning of a business day, wherein said validation request electronictransmitting step occurs upon the receiving of transaction informationfrom the online entity, and wherein said release list electronictransmitting step occurs at the end of the business day.
 39. A methodaccording to claim 22, said credit request electronic transmitting stepincludes: electronically creating a release list of requests to release,if a release list does not already exist; electronically transmitting avalidation request of the credit request to the payment processor;electronically adding the credit request to the release list, afterreceiving a confirmation that the credit request is valid;electronically transmitting the release list to the payment processor;and discarding the release list.
 40. A method according to claim 39,wherein said release list electronic creating step occurs at thebeginning of a business day, wherein said validation request electronictransmitting step occurs upon the receiving of transaction informationfrom the online entity, and wherein said release list electronictransmitting step occurs at the end of the business day.
 41. A methodaccording to claim 37, wherein the release list in said debit requestelectronic transmitting step is a debit release list, and wherein saidcredit request electronic transmitting step includes: electronicallycreating a credit release list of requests to release, if a creditrelease list does not already exist, the credit release list beingdifferent from the debit release list; electronically transmitting avalidation request of the credit request to the payment processor;electronically adding the credit request to the credit release list,after receiving a confirmation that the credit request is valid;electronically transmitting the credit release list to the paymentprocessor; and discarding the credit release list.
 42. A methodaccording to claim 22, wherein the payment processor closes the discretefinancial account upon completion of all payments for the transaction.43. A method of coordinating a plurality of payments, each paymentcorresponding to an online transaction between a seller and a buyer foran item, comprising: electronically receiving, for each of the onlinetransactions, bank account information from an online entityadministering the online transaction, the bank account informationincluding information on (1) a seller bank account corresponding to therespective seller, and (2) a buyer bank account corresponding to therespective buyer; electronically receiving, for each of the onlinetransactions, transaction information from the online entity, thetransaction information including a payment amount to be paid by therespective buyer to the respective seller for the respective item;electronically transmitting a batch debit request to a paymentprocessor, the batch debit request including instructions to, for eachof the online transactions, (1) create a discrete financial accountspecific to the online transaction, (2) debit, from the respective buyerbank account, a debit amount equal to or greater than the respectivepayment amount, (3) transfer the debit amount to the discrete financialaccount, and (4) hold the debit amount in the discrete financialaccount; and electronically transmitting a batch credit request to thepayment processor, the batch credit request including instructions to,for each of the online transactions having a confirmation that therespective buyer has received the respective item, (1) transfer a creditamount from the respective discrete financial account, and (2) credit,to the respective seller bank account, the payment amount, wherein saidbank account information electronic receiving step, said transactioninformation electronic receiving step, said debit request electronictransmitting step, and said credit request electronic transmitting stepare implemented using at least one processor and at least one memory.44. A method of coordinating payment between a seller and a buyer of anonline transaction for an item, comprising: electronically receivingbank account information, the bank account information includinginformation on (1) a seller bank account corresponding to the seller,and (2) a buyer bank account corresponding to the buyer; checking theseller bank account and the buyer bank account for security compliance;electronically receiving transaction information, the transactioninformation including a payment amount to be paid by the buyer to theseller for the item; electronically creating a discrete financialaccount specific to the online transaction; electronically debiting,from the buyer bank account, a debit amount equal to or greater than thepayment amount; electronically transferring the debit amount to thediscrete financial account; holding the debit amount in the discretefinancial account; electronically receiving a notification that thebuyer has received the item; electronically transferring a credit amountfrom the discrete financial account; and electronically crediting, tothe seller bank account, the credit amount, wherein said bank accountinformation electronic receiving step, said transaction informationelectronic receiving step, said electronic creating step, saidelectronic debiting step, said debit amount electronic transferringstep, said notification electronic receiving step, said credit amountelectronic transferring step, and said electronic crediting step areimplemented using at least one processor and at least one memory.
 45. Amethod according to claim 44, wherein the bank account informationreceived in said bank account information electronic receiving stepincludes information on a plurality of potential seller bank accountscorresponding to a plurality of potential sellers for the onlinetransaction, one of the potential sellers being selected as the sellerfor the online transaction, wherein said checking step includes checkingthe plurality of potential seller bank accounts for security compliance,and wherein the transaction information received in said transactioninformation electronic receiving step includes information on thepotential seller out of the plurality of potential sellers that has beenselected as the seller.
 46. A method according to claim 45, wherein saidbank account information electronic receiving step is performed prior toa completion of negotiation of the online transaction, wherein theseller is selected out of the plurality of potential sellers during thenegotiation of the online transaction or at the completion ofnegotiation of the online transaction. and wherein said transactioninformation electronic receiving step is performed after the completionof negotiation of the online transaction.
 47. An apparatus forcoordinating payment between a payor and a payee of a transaction for acontractual obligation, comprising: a bank account information receptionmodule that receives, from an online entity administering thetransaction, bank account information including information on (1) apayor bank account corresponding to the payor, and (2) a payee bankaccount corresponding to the payee; a transaction information receptionmodule that receives, from the online entity, the transactioninformation including a payment amount to be paid by the payor to thepayee for the contractual obligation; a debit request transmissionmodule that transmits, to a payment processor, a debit request includinginstructions to (1) create a discrete financial account specific to thetransaction, (2) debit, from the payor bank account, a debit amountequal to or greater than the payment amount, (3) transfer the debitamount to the discrete financial account, and (4) hold the debit amountin the discrete financial account; and a credit request transmissionmodule that transmits, after a confirmation that the contractualobligation has been at least partially satisfied, a credit request tothe payment processor, the credit request including instructions to (1)transfer a credit amount from the discrete financial account, and (2)credit, to the payee bank account, the payment amount.
 48. A computerprogram product comprising a non-transitory computer-readable mediumhaving control logic stored thereon for causing a computer to coordinatepayment between a payor and a payee of a transaction for a contractualobligation, the control logic comprising computer readable program codewhich, when executed, causes the computer to perform the steps of:electronically receiving bank account information from an online entityadministering the transaction, the bank account information includinginformation on (1) a payor bank account corresponding to the payor, and(2) a payee bank account corresponding to the payee; electronicallyreceiving transaction information from the online entity, thetransaction information including a payment amount to be paid by thepayor to the payee for the contractual obligation; electronicallytransmitting a debit request to a payment processor, the debit requestincluding instructions to (1) create a discrete financial accountspecific to the transaction, (2) debit, from the payor bank account, adebit amount equal to or greater than the payment amount, (3) transferthe debit amount to the discrete financial account, and (4) hold thedebit amount in the discrete financial account; and electronicallytransmitting, after a confirmation that the contractual obligation hasbeen at least partially satisfied, a credit request to the paymentprocessor, the credit request including instructions to (1) transfer acredit amount from the discrete financial account, and (2) credit, tothe payee bank account, the payment amount.